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(54) Events as activities in process models of workflow management systems 



(57) The present invention relates to the area of 
workflow management systems (WFMS). WFMS exe- 
cute a multitude of process models consisting of a net- 
work of potentially distributed activities. The current 
invention is dedicated to the implementation of events 
within WFMS. The current invention teaches to imple- 
ment events like any other process activity. 
Thus events are implemented as event-activities, a spe- 
cial type of an activity within said WFMS. Such an 
event-activity can manage an event occurring internal or 
external to the WFMS. 

This approach allows to make all features available to 
common activities also accessible to event activities: 
examples are: input-container and/or output-container, 
control-connectors, data-connectors, notification-mech- 
anisms, predicates associated to control connectors 
forming transition conditions and many more. A control 
connector leaving an event activity, which optionally 
may be associated with a logical predicate as outgoing 
transition condition, allows the WFMS to automatically 
activate a target activity rf said event activity terminated 
after the event has been signaled to said event activity 
and if the outgoing transition condition evaluates to true. 
Similar an incoming control connector, which optionally 
may be associated with a logical predicate as incoming 
transition condition, allows a WFMS to automatically 
activate an event activity if the process activity being the 
source of said incoming control connector terminated 
and if said incoming-transition-condition evaluates to 
true. 

This invention also teaches to extend the navigator of a 
WFMS by an event management system which inter- 



operates with the navigator to deliver above mentioned 
functionality. The event management system encom- 
passes the component of an event monitor administer- 
ing awaited events in a awaited event table and further 
administering signaled events in a posted event table. 
The event management system further encompasses 
the component of an event manager maintaining infor- 
mation on events allowing to verify correctness of an 
event. 
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Description ; ^ ; r 

1 Background of the Invention * - 

--.■*-■ < c , , 

1.1 Field of the invention ^ - ■ 5 

The present inventionrelates to the field of compu- 
ter systems acting" as workflow management systems 
(WFMS). • ' • * - - : - 

1.2 Description and Disadvantages of Prior Art j 

A new area of technology with increasing impor- 
tance is the domain of Workflow- Management-Sys- 
tems (WFMS). WFMS support the - modelling and is 
execution of business processes. Business processes 
control which piece of work of a network of pieces of 
work will be performed by whom and which 1 resources 
are exploited for this work,' i.e: a business process 
describes how an enterprise wi!i achieve its business 20 
goals. The individual pieces of work might be distributed 
across a multitude of different computer systems con- 
nected by some type of network. ; ■■■■ v 1 ^ 
The process of designing, developing and manu- 
facturing a new product arid the process of changing or 25 
adapting an existing product presents many 1 challenges 
to product managers and engineers to bring the product 
to market for the least cost and ' Within schedule while 
maintaining- or even increasing product " quality. -Many 
companies are realizing that the conventional product so 
design processes not satisfactory to meibfcthese needs. 
They require early involvement of manufacturing engi- 
neering, cost* engineering; logistic pfenning, procure- 
ment, manufacturing, service and support with the 
design effort. Furthermore, tiiey require planning and 
control of product data through design, > release; and 
manufacturing. *- 5 ' Vf *^ - ^- ^' 

The correct arKPefficierit execution of business 
processes within a company. e. g. d^eloprnent-6r pro- 
duction processes; is *of :r feriormous importance for a 
company and has significant Influence on oonpany's 
overall success in the market 1 places Therefore,' those 
prbc*3sses have to be regarded similar as technology 
processes and haveto be tested; optimized and moni- 
tored. The management of such processes is usually 
performed and supported by a computer based process 
or workflow management system. * d : ■•:-•-« 
: r Ih -d/ J. Spoon; r "Project Management Ehviron- 
mentV IBM Technical Disclosure Bulletih/.A/6l.'32, Nb. 
9A, February 1990, pages 250 to 254, a process nian- 
agemerit environment is described including? an operat- 
ing environment, data elements; and' application 
functions and processes: ' ■' 5:m> - r *"' r * ' 
' ; In R; T. " Marshak: "IBM's FlowMark, Object-Ori- 
ented Workflow for Miss^on-Critica^App^icat^ons ,, . Work- 
group Computing Report (USA), Vol. 17; No. 5; 1994, 
page 3 to 13, the object character of IBM RowMark as 
a client/server product built on a true object model that 



is targeted for missions-critical production process appli- 
cation development aind deployments described. .* 

* In .Hr A. Inhissrahd'J. H. Sheridan:-" Workflow Man- 
agement Based on an Object-Oriented Paradigm", IBM 
Technical Disclosure Bulletin. Vol. 37, No. 3, March 
1994 7 page 185, otheraspects of object-oriented mod- 
elling on customization and changes are described. . 
- ;ln F. Leymanmand D.. Roller: "Business Process 
Management with FlowMark^; Digest' of papers, Cat. 
N0..94CH341 4-0, Spring COMPCON.94, 1994, pages 
230 to 234, the state-of-the-art computer process man- 
agement tool IBM FlowMark is described. The meta 
model' of: IBM FlowMark is presented as well as the 
implementation of IBM FlowMark. The possibilities, of 
IBM FlowMark for modelling of business processes as 
well as their execution are discussed. The product IBM 
FlowMark is available for different computer platforms 
and -documentation for IBM FlowMark is available Jn 
every IBM branch. " - 

1 . M imF; Leymahn: "A meta model to support the mod- 
elling and execution of- processes", Proceedings of .the 
11th- European. 1 Meeting on ^Cybernetics and System 
Research EMC R92< c Vienna,* Austria, April 21 to 24, 
1992, World Scientific -1932, pages 287 to 294, a meta 
model for controlling business processes is presented 
and discussed in details o ; --l >■■ : , - , 

r , The "IBM FtowMark for OS/2", document ^number 
GHcl 9-821 5-01, IBM. Corporation, 1994, available in 
every-' IBM sales office; represents a typical modern, 
^sophisticated, and powerful workflow management Sys- 
tem.^ supports the modelling of business processes as 
& network* ol aetivities;crefer for insiance to "Modeling 
.Workf low^document number SH 1 9-824VIBM Corpo- 
ration, 1996: This network oft activities; the process 
model, is constructed: as a directed/ acyclic, weighted, 
^colored graph, r Xhe nodes of: the graph* represent the 
activities or :<workitems /which" are performed. The 
edgesrof the graph; the control connectors,:describe 
the' potential sequence^bf execution of the activities. 
40 Definitrpn of the process graph isviathe IBM FlowMark 
Definition Language (FDL) or the built-in graphical edi- 
tor. The runtime component of the workflow manager 
interprets the process graph and distributes the execu- 
tion of activities to the right person at the right place, e. 
45 g. by assigning' tasks to a work list; according to the 
respective person/ wherein said work . list; is stored as 
digital data within said workflow or process manage- 
ment computer system. 

In BLeymann and W. Altenhuber : "Managing twsj- 
50 ness processes as an information resource", IBM Sys- 
tems Journal; Vol. 32(2), 1994, the mathematical theory 
underlying the IBM FlowMark product is described 

In O. Roller: ■Verifikation von Workflows in IBM 
FlowMark". in J; Becker und G. Vossen (Hrsg.): 
55 "Geschaeftsprozessmodellierung und Workflows*. 
International Thompson Publishing, 1995, the requ*e- 
ment and possibility of the verification of workflows <s 
described. -Furthermore the feature of graphical amma- 
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tion for verification. of the processrlcgicHs preseeted as 
it is implemented within the IBM^itewMsrk product. 

Fop implementing a computerbased'prdcess' man- 
agement system, firstly, the business processes have to 
be analyzed and, as- the result of this analysis, a proc- 
ess model has to reconstructed as a network of activi- 
ties corresponding to ,ther business. process. In thejIBM 
FlowMark. product, the process models -are not trans- 
formed into an executable/: At /run : time, .an? instance of 
the process is created from the process model, called a 
process instance. This: process- instance is then inter- 
preted dynamically by theHBM FlowMark product -r- 
; - The concept of events as such on the other hand is 
known in the state' of the art Events for example play a 
role in database management systems. In database 
management systems eventftGtgger mechanism have 
been developed for consistency checking in databases 
as described for instance in A. M: Kotz, Triggermecha- 
nismen in Datenbanksystemen, Springers Vertagj Berlin 
1989. Also events play :a central rolevin the f ribtion of 
active databases, tntworkflow systems; the semantics 
of an event is quite, imprecise : as- (appHedrbyr A- W. 
Scheer, Wirtschaftsinfbrmatik- Springer* verlag;- Berlin 
1994 , where the event can be a termination condition of 
a previous activity or an external; signal; such as the 
arrival of a letter or in general an incident occurring 
independent frorri an actiy ityj informing activity, asyn- 
chroneously on some'typexrfxhafllSe. According; to this 
prior art approach an- event is restricted to a <CjUiteJjrri'- 
ited spectrum of possible ^^Crtmresi-'The.erelatipnship 
between trie activity and the event may b&syotethat.the 
activity requires that the event is signaled tsx rtaDtbarwiss 
the activity wilt not cohtirtue^beyondsarcertain poftfoft is 
also possible that an event signaled to tin activity wJJI be 
perceived byttiat activity and depending on that percep- 
tion might modify; the actrvity'siQngotfiij prpcessingMn 
event might: result ifrom^anywrw^wtthin.a computer 
system' of even within: networks- of .computer -systems. 
Also the source of an; event might be a hardware device, 
some software construct;; a^rujErnan,^ 
runningiGomputersystem and^o fo0b-:pH;;, : r o.T niioJ 

1.3 Objective of the Invention . i , <? »o ^ ; 

The invention is based on the>.objecttve4o tightly 
integrate eventmechanismsrirrto workflow tnanagement 
systems.* ..• :»«. .->.>r ■ i v.- -j?:?-. ^-i/-: 

2 Summary .and Advantages of the Invention . j 

The objective of the invention is solved by clatrn. 1. 
WFMS, encompassing one or mote computers, execute 
a multitude of process models consisting of a network of 
potentially distributed activities. -For- each activity infor- 
mation is defined within the WFMS which avaitabtepro- 
grams or processes do execute that activity. The ourrent 
invention teaches to realize an event as an event activity 
encompassed by said process model said event activity 
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being implemented as a special type of activity of said 
WFMS and said event activity managing an event which 
may occur internal or external tenths WFMS. 

The technique proposed by the current invention 

5 achieves a new level of integration between WFMS and 
event technology. By exploiting and reusing the activity 
features very economic implementations for events are 
achieyed.rln additionconceptual gaps between the con- 
cepts of activities such as program or process and 

w events are completely avoided. Moreover the approach 
allows to handle:both, events occurring due to incidents 
within the WFMS as well as events having their source 
external to a WFMS. By conceptually handling an event 
a&any other activity (for instance as a process activity), 

75 this concept, allows to treat really any type of incident 
within a ,wnnputer'.sy^rr> as an,;. event. The current 
approach thus supports the broadest possible spectrum 
of possible events. By^ reusing to a certain extend the 
implementations . of activities^ the ■ overall system ; of a 

•so WFMSjjs not, increased -supporting, compact and very 

responsive ^overall WFMS : o - ~- ... . 

* *rs AdditiQnaladvantages -pt the invention are accom- 
plished by claim 2. >•>,■,.;: r 
According thi^ teaching ^id^event activities are imple- 

55 merited by inheriting features arg*capabiljties of the 
clasSrOf activities or of a ;Sufc**q!ass thereof according to 
the principles rofjc^jectrorj^ . . 

' Such an: :apPfoach>allows : for <an elegant and very 
sri^le way of fj^jLisin^ available 

&o within a astern. vp r*v- : 

j:,rKFu^h€T\-cKiditional;€U^ant9ges. of the^inyerrtion are 
apcorrpHshed : by dairp3.; • t . v: : . , .. 
Claim 3 teaches to implemeql event activities by associ- 
ating with it an. event generator being a program imple- 

m Renting said event. According tQ.ttie invention an event 
Laetivrtyrnay haye^associated -with it ar? Input container 
anchor an output-container, the event activity may be the 
^^Mfce.and/or, t^get-pf one. or more controj-connectors 
^nc> the?eyentact»Yity fnay b&thespurce and/or target of 

40 ^neior^rrHDre^ata-.^ by 
jhei current teaching. -that the -event activity, may, be 
f^Bspciated with a ? notification mechanism allowing, to 
vJrejaly define pn$.or- rncxe.actipns to be permed by the 
W^SrittS^e event activity is not completed i within a 

0^5 fr : ^y,de*irj^ time period. ^ r , v - , . . , , ., ; -/ 
Hc v • This approach tp events supports a cor^ete tiari^- 
parency whether an jsver^: is pi internal or ; external 
natures Nevertheless the teaching aJlows tp implement 
,tf>e eyenti generator as a c special , purpose ^prograrn 

■-so implerrienting or handling really any type of , event, Sep- 
fff€Kbp5rthe general aspects of an event. Jike signali^a 
dedicate^ consumer that the event happened,, from t^e 
event generator avoids that these functions have ,to ^e 
realized; over and. ; over again. Instead, these, general 

55 . aspects .are Jmr^emented only^g^©. w^hin tiie VVIfMS 
ard ar<e handled by the yVFMJS a^omatycaily. Of pourse 
; features which .are available to normal activities are 
rrnade^ayailable to event activities too ; thus easing the 
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implementation of events 'significantly:'. For instance 
input and output containers allow to provide an event 
generator with run-time information or to make results of 
ah event available to consumers dl an event. 

Further additional advantages of the invention are 5 
accomplished by claim 4. 

The invention suggest to introduce as one possible 
action which may be performed' by the notification 
mechanism to automatically terminate the event if the 
event is not completed within a predefined time period. 10 

Such an approach allows to simulate a successful 
termination of an event activity if required. 

Further additional advantages of the invention are 
accomplished by claim 5 and 7: 

The current teaching allows that an event activity may is 
be the source of one or more outgoing control connec- 
tor targeting at corresponding target activities. Such a 
pr r .-*ss model will therV make sure that the target activ- 
ity fH\\ be informed alrtornatically by the WFMS on the 
evem once the event is signaled to the waiting event so 
activity an the event "activity terminated. An outgoing 
control connector optionally may be associated with a 
logical predicate as outgoing transition condition mode- 
ling the fact that a target activity will be activated rf said 
event activity terminated and sad out&oirig transition 25 
condition evaluates to true. TTi$ '^<^'^ m ^ 
thermore teaches that one oTmoifc incorhing control 
connectors of the corresponding sbdrce activities may 
targeting at an event activity, ^^f^^^nfM^ 
then allow the WFMS to afflbflfeti^lV^rtth'e 30 
activity once a source activity terminated its processing. 
An incoming control connector optionally may be asso- 
ciated with a logical predicate as incoming transition 
condition modeling the fact that the event activity will be , 
started only by the WFMS if jh addition said incoming 35 
transition condition evaluates to true. ; ; r ^ f ; v . 

By this approach already ^ process ^r^pH allows 
to define via the<x>ntroi tom'lp^^ activi- 



ties are to be started after an event or'WIiicH prpcess 
activities automatically; start an werft^actiyity: TThis; tech- 40 
nique establishes a standard laj^bach to informpoten- 
tial consumers on an event and tost£rtan event activity 
and event generators: Thus the event; activities, ( the 
event generators "of the potential; "wnsumers are 
relieved from; performing extra activities for that, pdr- 45 
pose. Moreover ; e^ent ' "genferaidrs and Went activities 
with interest in a certain event (either in seating or in 
waiting on an event) Become sighifira^ 
ment. In addition ^ve'mi^tio^ t>fthe 
events is done airtom^tically by t^ WFMS. The current so 
invention does not restrict these source arid target activ- 
ities to a specific type of WFMS activities. Therefore the 
source and/or target activities migW represent standard 
process activrties/.pr^ of . 

activities but according to the current invention if wotild 55 
be also possible that one or both of them represent also 
event activities. In other wordsthe current invishtion also 
supports chains or even complex graphs of event activ- 



ities. 

FUrther^aj^^ 
accomplished iby c $aim6. 

According claim' 6 the VvTMS is; activating an event 
activity automatically when instantiating a process 
model if said event activity is not a target of a control 
connector. if - - 

Thus no extra implementation is required to start a 
certain event generator. The WFMS takes care about 
these aspects automatically. 

Further additional advantages of the invention are 

^ornplished by claim 8. 

According to claim SlheWFMS registers said event 
activity as awaiting consumer of said event once said 
event activity is activated by the WFMS and wherein fur- 
ther skid WFMS registers said event as posted event 
bnce the <x;cuneiTee bf said event is signaled by said 

£veftt ^erierator. ~ 

- Due tbtiiis teaching again the implementation of an 
ev^hf activity becomes mUch easier as" the interest in a 
Certain event is automatically detected by the WFMS by 
reading the process graph and the WFMS takes over 
responsibility to register an event* activity's interest in 
that ev^nt. Moreover the implementation of event gener- 
aiors'is also significantly simplified as atf event signaled 
r bfan event generator is V^istercd automatically by the 
WFMS as posted event. ; ' - : ; "* ■ ' ■ 
— ' Further acWitidferaclvantages of the invention are 

^S^isffedby^dal^ " 
^is teacWirVg suSg^ activity is activated 

by said 1 WFMS L tf ^ a first condition the event activity 
^rrhinated^n^ if as a secdnicl condition- theToutgbing 
transition condition evaluates to true 1 independent at 
"wtiicW^imirtfime and In which sequence said first and 
said second condition are fulfilled. ' V 

this^behav^ ch^acteristic^ avoids 'tHat the sig- 
; hafdci c everft is' "consumed" if the transition condition is 
not fulfilled "exactly at the point in time the event 

mirred:^ - ^ ^ rfc ' ' ' 

r " Turth^^additional advantages of the invention are 

: a^drr^iishSd By cfaim 1 0V ! ' 
L Claim lO^Uggest to extend the WFMS navigator, per- 
forming navigation of -c^eratibn trough the process 
graph of a process-model, by an event management 
system extending and inter-operatihg with said WFMS 
navigator. The event management system encom- 
passes th4 component of an event monitor administer- 
ing awaittx* events in at least one awaited event table 
and further administering signaled events in at least one 
l= pos&d 'event Wile. An event generator is signaling the 
: occurrence^ said evcsnt to said event monitor. 

This teaching extends thtf navigator with additional 
features td Administer oh one side-al i events which have 
been signaled to and to handle on the other side all 
potential consumers of an event and to associate both 
sides. Nefthereveht generators nor activities do have to 
tike care of these aspects. : 

"Further additional advantages of the invention are 
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accomplished by claim 1 1 . 

The teachi.ng.pf claim. 11 sugge^^ c a^yent manage- 
ment system encompassing the component P* an event 
manager maintaining information pn the events allowing 
to verify correctness' of an .event if saidjevent is. being 
signaled.. ......,/ 



Such an access further increases the reliability of 

thehoverall system.. - 0 :.'vr-vr -vio--*! ...w..., r: FT" 

Further additionai.adyanta^e^ oif.^e-inyentipn. are 
accomplished by claim 12. t „ . ^vsi, . - ...v r; ; > . 
According to claim 1 1 the WFMS sends, if it deteqts that 
an event activity is awaiting for an event v an awaited 
event notification^ said event monitor and if men. said 
event monitor detects, a matching posted Qvlept, ,indica- 

.tion in said posted event tabie said event ,monitor : -indi- 
cates said event together with event data to said.^VFMS. 

Jf otherwise no matching postedi ev,ent ^otrfjpation is 
detected said event monitor stores an aw$i|£d teygpt 
indication in said awajted ey^nj.t^ble. Alsq according to 
claim 12 said event generator indipatgs .the^ ocQurjeng.e 
of an event by a posted, eysnt indication to saty event 
monitor which; yerifies s^id , posted, , event indication, by 
consulting . said event manager ^od ^n^pres^said 
posted event indication in.said^st^^vei^ t^je^cljf 
then said event monitor ^ejeqis a> { matching .awafrjng 
event indication in said awaijing event t§We it i^dipates 
this together with event data to*ttie Wj"jMS. Q r .^VT^A 

... : - The approach of claim .1 2. i^ifoy^r^spqq^iyfness 
of the WFMS by at once ch^q^^ 
new, event arrived or.a.new^cori^^ 
event whetber r a maJcNng ^^t-cgn^m^pai^ 

. detected- ajlowii*g 7 the vyFM.§;to 'g^^^^i^ti^t 

on the signaled event. ? .: f .,.j-i. vs ric-frhr,;,.. n>z & *a 
* ^Further .addfto&al ajy^ntages, Qtjh? jqyentioi^ are 
accomplished by claim 13 r . ^ ^ : ^ >no0 & ICW , r 
Claim 13 teaches that ^nifye^ener^torHis informed, if 
. an awaited, eyent Wication jj^^tprgd ig sE|jg, awaited 
. event table,- on this awaited event ix^palioa,^ : > ^ . 
This technique informs an event genera^ gj(Jrtp- 
matically on consumers .aw^ng soiree, kigdypf : event. 
Such an approach avoids that an event ^ g^.n^aifpr. peri- 
odically has to check fqnpqssjble eve^f^r^umef^ahd 
. thus avoids performance^degradaticps^,r u( .- . lir .. , ,< 



Figure 6 is a visualization qf the FDL definition of 

. an event. ...^ .... 
Figure 7 : is a visualization of the FDL definition for 
> exploiting.*the, notification mechanism for 
5 an>event t 

Figure 8 is a simple sample, process model reflect- 

, . ing the usage of event activities 
Figure 9 . reflects,. the most important data struc- 
tures of the example of Figure 8 .. , 
10 Figure 10 is a. visualization,^ an event modeled as 
V • . . ^n event activity within.the process model 
of .the example of Figure 8 



4 Description of the Preferred Embodiment 
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The current invention is. illustrated based on IBM's 
FfowMark workflow management system. Of course 
any other VVI^ u^ed^instead,: Furthermore 

the current teaching ^pUe^ also to any . other type of 
T %o .system wtych off^^ ty^M$ functionaiiti^ not as a sep- 
arata WFMS bpt within, sbnie QtJrtQr. type of system. 



4.1 Introduction 



■ ■ 1 1 . 



3 Brief Description of the, Drawings, , /; 



Figure 1 : 'S.a diagram-reflecting multiply aspects of 
, ; the embedding of events 3s a.,new ^be of 
activity within a WFMS >; ~, ' . 

Figure 2 r; is a visualizatipn ot the ; two fuoctemerttal 
embeddir»9 modes of . evjB.nts (i as . eyent 
activities within a prqce^ JT*pdel T 

Figure 3 reflects the major, coJTPPperTts of. tbe 

r Event ManagemenJ Systern.,-. ; .; . 
Rgure 4 . depicts the structure of tf?e ^ "awajted r ey v ^nt 

. . table" and the, "posted event tablV :> 
Figure 5 is a visualization of -the FDL registration 
definitions required to model an event 



;i 25 , : .JTie %>l(owin^ is. t .a sjiprt qutline on the basic con- 
cqpl^.of Ja. woiWJpw based on 

Jbms FjwM^ . ^ ; ;;^^ f .^J . ^ 

, 5rom f ,ari enterpri^ point plyiew the "management 
..g| ^sineM.^QC,^^^S.is becoming increasingly ..impor- 
30 jtent: *bu$inii& for short control 

wtiich pi.^pe f bj '.wr^wili be performed by whom and 
whucK resources' are exploited^ for this work, Le. a busi- 
ness proces^ T describes hpyy ; an enterprise will achieve 
Jits » ^usinje^s goals. A WFMS may support both, the 
35 . mc^eling of b^sine^.p^b9^ 

' Modeling of a i businessi. process as a syntactical 
^ni^jn f ,w^y th,^ is. directly ^ ^pported by a software sys- 
tei^ js^e^eip^ the software sys- 

tem. caa,^P?wq^ getting as 

.40 jnput.'such^a model:'' T^e?mjWel u , called a process 
mqdel qr ( * workflow mo^er can then be instsiritiated 
. 'a^djjthe, ji^V^Maj. s^'0e ( qce.'6f work steps ^depending 
/on the context of tfie instantiafipn of the model can be 
^^eterntiiped. Such a model of a business process can be 
. 45 ^p^ceiVed.as a template ^ for a ^ class df simjfarproceises 
; peVfo/mecj within an Enterprise;, it is a schema de^crib- 
jng dljroi^ty^ 

busiriess ^process. An instance of such a mbdei and its 
^/rfterpretatjpn represente an individual process, » f a 

.50 I^npretK'cdnt^ d^'erWem;;execuipn of S .variant pr : e- 
; scribed by the mod^L A WFMSs facilitates the manage- 
_ ment of . business processes^ It provides a means to 
. d^icribe models ipf tiusirie^'prpce^ses (build time) and 
.^it'^nyes ^^ness 'prwe&es 'taded.'bn an associated 

. 55 ^mbb^l (cun .time): TH6 meta ftibderbf IBM's WFMS 
^J^jQif^qrHi, ""i.e.. th^ syntac^tei ej^rfifents p^ovndied for 
l'3^cribing business pibcess models, and the m^anmg 
" and interpretation of these syntactical dements. * 
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described next. . : • i • c ,*:. 

A process model is a complete representation of a 
process, comprising a process diagram and the settings 
that define the logic behind the components of the dia- 
gram. Using various ? services provided by FlowMark 
these buildtime definitions the process models are then 
converted into process templates for use by 'FlowMark 
at runtime. Important components of a FlowMark proc- 
ess model are: r -'■ Vr fi 
y ' - • ' 

b Processes * iri > ' * ^ 

■ Activities t:.- 

■ Blocks r ' " " r "* - " * ' 
b Control Flows ' - ' ~ ' r l " ; 

■ Connectors ■ ''^ - 
a Data Containers . > : 
b Data Structures : 

b Conditions n fc ^ 

b Programs ' '" 1;l 

■ Staff ■ ~- 

Not all of these elements will be described below. : 
On this background a process, modeled by a^prbc- 
ess model within FlowMark; is a sequence of activities 
that must be completed to accomplish a task- The proc- 
ess is the top-level element of a FlowMark workflow 
model. In a FlowMark process; it* can be defined: : : 

• How wbrk i£ r to progress from one Activity to y the 
next ' 1 ' - ' 

Which persons are to perform activities and whiat 
programs they are to use 

Whether any othef processes, balled - subproc- 
esses, aire nested in the process • • 1 ■ 

Of course multiple instances of a FlowMark process can 
run in parallel/ :. -^v.^v : y \- 

Activities are the fundamental ^glemen^^-df^the- 
meta model. An activity represents ai J busir.ess action 
that is from a certain perspective a serartticar entity of 
its own. With the model of the business procdss it might 
have a f irie^structure that is then represented irr turn via 
a model, or the details of it are not of interest at all from 
a business process modeling point of vie^^^ Refinement 
of activities via process mbdels r allows for both, mode- 
ling business processes bottom-up and top-down. 
Activities being a step within a process represents a 
pifeiie bf work that the assigned person cart conipiete by 
starling a program or another process/ in a process 
model,' the following information is associated with each 
activity: : * v '" '---^ ■- - ' '< r ^'* 

What conditions must be met before the activity can 
f ; start r \ ■ [ " /" "'* ' ■ ■■ - / 

• Whether the activity must be Started "manually by a 
user or can start automatically ' ' !; 

What condition indicates that the activity is cbm- 
' plete • 



Whether &rftrdl&an exit from the activity automati- 
^ - • cally or the activity tnust first be confirmed as com- 
" plete by a'us&r vt'\ ; y « v ; . 

• %How much time is allowed for completion of the 
5 activity r - ' ^ 

• 1 Who is re£ponsible : fbr completing the activity* 

Which program or process is used tocornplete the 
' activity " - v VOi ^ ■ ; "* 

• What daita is required as input to the activity and as 
w dtitpuffrom rt : :x 

A FlowMark process model consists of the following 
types of aictivities: .... 

is f Prog ram activity : Has a program ; assigned to per- 
! forrn it The program is invoked when the activity is 
started. In a fully automated workflow, the program 
- performs the activity without human intervention. 
^ : Otherwise^ the user must start the activity by select- 
~2d 1 " ih'jpit from a runtime work list. Output from the pro- 
- 1 gram can --be used in the exit condition for the 
" n: prbgiram activity and for the transition conditions to 
other activities. ^ " ^ • s - *' " - 
Priocsss activity: Mas a (sub-)process assigned to 
25 ■"*■' -perform it -The processes invoked when "the activity 
:^ T is started. A process activity represents a way : to 
~ l reuse a setof activities that are common to different 
^processes ■ Output 1 from the process, can be4jsed in 
^ ^ thg exit cdhditioh for the process activity and for the 
30 • : j^tr^hs^oH f coridftidns"to other activities: ^: 1 ■ 

-ii y^^^t^^^ni^: i.e. the controi itew through a 
ruhhihg' prbe'ess'd^errhines^the sequence " in which 
'ddtivitf^'^ r ieKectA'ed: the FiowMark workflow 5 man- 

35 aiger hiavigates a path through the process that is -deter- 
mined by the'evaruation^o -trOe of start conditions, exit 
^Acfrtlbhs, andliansition conditions. " : '-x 

■= The r^Ms r that" are in general produced by tie 
wor^n^^ent"^ activity is put into- an output 

4o ^container) which 7s associated with each activity. Since 
^•activity wlit-Tn -general- require to access output con- 
tainers br-btfrer activities, each activity is associated in 
acfciitioh with kri f -input eositasner too. At run time, -the 
aduaTval&es for 7 the forma! parameters building the 

7 45 irpih r cbntaiher of an activity represent the actual con- 
text bf an 'ihsitahce of the activity. Each data container is 
defined by a data structure. A data structure is an 
ordered list of variables/ called members, that have a 
name and a data type. Data connectors represent the 

: so transfer of data from outpiit containers to input contain- 
ers - When m a data connector joins an output container 
'with an input container, and the data structures of the 
two container^ match exactly; the FiowMark workflow 
manager maps the data automatically. 

55 Connectors link activities in a process model. 
Using cbnnectorsr one' defines the sequence of activi- 
ties and the transmission of data between activities. 
Since -activities might no* be executed arbitrarily they 
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are bound together, yia> control C9t?n^Ctor$: A control 
connector ^ might, beopefceiyedyflftr^t directed edge 
between two activities; the activity *ajt -the ponnector's 
end point cannot start before t^e,,activity at the start 
point of the connector has finished (successfully). Con- 
trol connectors rnode;l ti^us. th§. pptentjal f low, of control 
with in a bus; in ess .prpqes^ H??Ctel : P©*?" 1 ? . connectors 
specify where control should flow when the transition 
condijtion of no other? cprnrol .cpjanectpr ( 4eayir^ £n activ- 
ity evaluates to true. Default connectors : enable the 
workflow model to cope with exceptional events. Data 
connector, specifythe flow of data in a workflow model. 
A data connector originates from an activity, qr a block, 
and has an activity or a block as its target. One can 
specify ; that output ; data,is to gp to one target or tp.mul- 
tiple targets. A target can. have mpre tharvqne inpoming 
data connector. - % ■ > >> .^ , : i ■-. r 

Conditions are the means by:yyjhieh it is possible to 
specify the flow of icontroUnra prpce$$, :lrv£lGwMark 
process models logical expressions oanr be defin^d that 
are evaluated by FlowMark at runtirne-tc? determine 
when an activity may start, erxJ;' and. pass control to the 
next activity. Start conditions are conditions that deter- 
mine when anac#vity wjthmcQmjog c^n1^<^^nnectors 
can start. The start conditionmay specify that incom- 
ing control connectors must evaluate to trtie. or (t may 
spedfy thatrat least one. M^emrnust: evaluate tp.true. 
Whatever the start^con^rttonnaHJtnrarning connectors 
must be evaluated befpFe the activity xw.sftwMiN an 
activity has noMncoming-CQntrp^Ger^ 
ready when the process or block containing it starts. In 
addition,: a Boolean expression o^ed transition condi- 
tion is associated with eachtoei^Qicogr^ctpfj f^ramer 
ters- from output; containers of agtiyJR^ Jiving already 
prcxjacedthek results,^ 

enced in transition corxiitionsnrV^^rtv^run* time- ap 
activity terminates successfully. ajhporrtfQl G$QnQ&Qf$ 
leaving this activity.sare ^termine^. ( and.J^i ; fri4h rvalue 
off the associated transition qpn^rtfe^siSv qtarnpkutsd 
based on the actual values pfrth^r: par^rnetter^jQnlyLth^ 
end points of control connectors thertrsns^PGi^ncji- 
tions of which evaluated; fc? TPUp ^e.ccpnsi^^^ as 
activities .that might be executed basejd en-the-^^tual 
context oHhe business process^? Transition, icpndjjiorjp 
model thus the context dependent actuak.flpw^f control 
within a business process .{i.e. a# instance; of %model). 
Business^processes encompass 4ong running activities 
in. general; such ■ an . activity need to be^allpweci % to 
become^ interrupted i-Thus; termination- of $n activity 
does not necessarily indicate, that 'the associated task 
has been finished successfully. In order, to allow, the 
measurement of successful! n ess. of the work^perfprmed 
by an activity a Boolean, expression called exit . condi- 
tion is associated with each : activity. Exactly the activi- 
ties the exit condition pf which, evaluated to trgerin the 
actual context are treated as successfully .ter^miriatjsd. 
For determination of the actual.cpntrpl flow precisely the 
successfully, terminated activities are c»nskJered : Thus 
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the logical expression of an exit condition, if specified, 
must evaluate, to true -for control to pass from, an activity 

orblock,.^ <: , .^ t , : _ ...... ....... . r . it . , .. ,. 

; Beside describing. the potential flow of control .and 

5 data between activities a business process model also 
encompasses the description of the flow of the activities 
itself between "resources" actually performing the 
pieces of. work represent^ by each activity. A resource 
may be specified as a particular program, person, a 

10 role, or an organizational unit. At run time tasks are 
resolved into requests to particular persons to perform 
particular activities resulting in workitems for that per-. v 
son. Staff assignments are the means to distribute 
activities to the right people in the sequence prescribed 

is by the control flow aspect of a business process model. 
Each activity in a process is assigned to one or ; more 
staff members defined in the FlowMark database. 
Whether an activity is started manually by the user or 
automatically by the FlowMark workflow manager, and 

go whether it requires user interaction to complete or com- 
pletes automatically, a staff member must be assigned 
to \t BowMark staff definition entails ; more than identify- 
ing people gi your enterpriseto the RowMark database, 
ppr §ach pereonjclefined, you c^n spepify, a level, an 

25 organization , : and multiply role^ .-These attributes can 
be ; used ^ : run ;tirne fo dynamically; assign i activities to 
people with ^jt^ei^il^es^-^j : 

In the FlowMark workflow manager, program 
rpeansa ^rnput^r-based application program that sup- 
so ports the work to be done in ah activity. Program activi- 
ties>, reference, executable prpgrapis using the jogical 
names associated with the, programs ip, FlowMark pro- 
gram registrations. Trje program registration, can con- 
tain run-time parameters for the executable program. 

35 FlowMark consists, at the coarsest level, of a build 
; tirne corrjponept .-and a, run tirne component The build 
time component supports the modeling .jof business 
r^pqes^i-ac^^ rpeta model ^described 

.a^pye ai$'tf}PJW tim^. component supports the corre- 

,40 spondingi ^. semantics., ^th . components are. imple- 
:t r^eniedJn :t a clien^eryer^uctijr^ ? The. client; delivers 
$\ e i i k?^^^? 0 ! *P}$. us ? r via ( Obiectroriented 
,-gr^phical. intecface f/ invpj^^lc^i.^tpls, and proyides 
:^imatj©T-V The server maintains the.database for proc- 

-45 ess, instances, navigates, through . the 

an0 ; assigns ihe acjiyrties to tfie proper respy reps. 1 1 1 
, ... Process definition jndudes,/ri^eling f qf a^iyjtl^s. 
/qpnbpL,: ^qonnertpreJDetween the . acti vities, . inpuVputpyt 
jcontairier, ,and : data connectors. , A process . is jepip- 

so -sented as ^ djrected acydic graph with the ap)jyities,as 
nodes and the control/data connectors as the edges of 
the graph. The graph is manipulated via a built-in, event- 
driven, CUA connpHant graphic editor. The data contain- 
ers are specified as named data structures. These data 

. 55 .^structures therrjselves.are spjecif ied yia.the DataStruc- 
tureDefinition facility^. FlowMark distinguishes three 
.main types of activities: program activities, process 
activities, and blocks. Program activities are imple- 
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mented through prograrns^The programs are registered 
via the Program Definition 1 facility. Blocks contain the 
same constructs as processes, such as activities, con- 
trol connectors etc. They -are however not named and 
have their own exit condition: If the exit condition is not 
met, the block is started again; The block thus imple- 
ments a Do Until construct.-Process activities are imple- 
mented as processes: These -subprocesses are defined 
separately as regular, named^ processes with all its 
usual properties. Process activities offer great-flexibility 
for process definition. It not only allows to;construct a 
process through permanent refinement of .activities into 
program and process activities (top-down), but also to 
build a process out of a set of existing processes (bot- 
tom-up). In particular, process activities help.to organize 
the modeling work if several process modeler are, work- 
ing together. It allows the team members to work .inde- 
pendently on different activities: Program and process 
activities can be associated with a i time limit . The time 
limit specifies how long the activity may take: lithe time 
is exceeded, a designated person is notified; If this per- 
son does not react within another time limit the process 
administrator is notified. It not only .helps to recognize 
critical situation but also to detect process deficiencies 
as all notifications arenrecordedin an.audtttrail. : . 

All data structures used as templates for' the -con- 
tainers of activities and processed are defined via the 
Data Structure-Defihitidh Facility. Data* Structures are 
names and are defined irv terms 6f :r e!OTerttary; data 
types, such as float, integer, or string ahd r^erehfces to 
existing data structures. Managing data structures as 
separate entities has the advantage thafail interfaces of 
activities and their implementations are managed con- 
sistently in one place (similar to header files in'program- 
ming languages). 1 vr 

Air programs which implement program activities 
are defined via the Program Registration Fa'cilityr Regis- 
tered for each prbgramts the name of m'e pfdgram, its 
location, and me invbcatibn string, the'irwocatloh string 
consists of the program name and the command string 
passed to the program? : — r -r' : ?> " : ' -- V; 1 - - 

Before process instances can be 1 created,- trife proc- 
ess model must be translated to ensure the correctness 
krid completeness of the process model. The translated 
version of the' model is used as a template when' a proc- 
ess instance is created / this aftbws' to make changes to 
the process model without affecting executing process 
instanced; A process' ihstende is started either via the 
graphical interface of via the callable process applica- 
tion programming interface. Wnen a process is started, 
the start activities are located, the proper people : are 
determined, and the activities are posted onto the work 
list of the selected people 1 . 1 if a user selects the 'activity, 
the activity is executed and removed from the work -list 
of any other user to whom the activity has been posted. 
After an activity has executed, its exit condition is' evalu- 
ated. If not met, the activity is rescheduled for execution, 
otherwise all outgoing control connectors and the asso- 



ciated transition conditions are evaluated. A control con- 
nector is select^/ if^the condition evaluates to TRUE. 
The target activities r of the selected control conHectors 
are then evaluated: If their start conditions are true, they 

s are posted to the wdrklist of selected people. A process 
is considered terminated, if ail end activities have com- 
pleted. To make siire ; that all end activities finish, a 
death path analysis is performed, it removes all edges 
in the-process graph which can never be reached due to 

to failing transition 'conditions. All information^ about the 
current state- of a process is stored in the database 
maintained by the server. This allows for forward recov- 
ery *i n th e case of crashes. 

is 4.2 Concepts 

. 1:-, "K. . > ■ ' ■ ■ t • ' * • -'" 

! To achieve an integration of events within WFMS 
which is as seamiest as possible the basic approach of 
*the current invention is to let events appear as a certain 

20 type of activity in terms'of a WFMS. More precisely this 
patent "application- teaches how events can be' treated 
arid implemented as a subclass of the class of activities 
inheriting (in the sense of object orientation) the com- 
mon properties of activities. : 

25 FlowMark activities are either program activities or 
process activities. Program activities are implemented 

* via a ; program which is invoked when the activity is exe- 
cuted; prccess ; activilttes &re implemented via a sub- 
process, which is started when the activity is executed. 

30 <Jhe secjuehce of execution- of the various activities of a 
i^rdcfess model aire rdeiscribed viathe control connectors. 
^Activities which are^oniy the target of control connectors 
^are cdi^ eii^'actiVities, activities which are only the 
source of control connectors, ^recalled start afctiVBties. 

'35 Which control connector is being followed is defined via 
Pptedicaies^ Each ^ Activity is 'associated with an input 
^cbfttainer and i an output 'container The input container 

* contains the data required by the implementation of the 
^activity to ^perform the correct processing; the output 

40 ^container is filled by the activity with information to con- 
trol 'the process and data to be used by subsequent 
-ietivitEfess-bata connectors are used to describe what 
data from which output container should be used for the 

* data c ih the -input container of activities Jsubsequent 
45 according to the process graph. Activities are associ- 
ated with a riotBtteat^ mechanism, which allows to 
specify r that an action, sucft as sending a notification 
message to a designated user, is performed: if the activ- 
ity has not been worked on for a defined period of time. 

so " ' . The v concept of events is the mechanism which 
allows the process modeler to specify that the process 
should wait at this point until the specified event hap- 
- pens: This ev^rit could be that a certain date occurs, or 
that a letter should be received from a customer. The 

55 occurrence of the event' may be signalled from an activ- 
ity within another process or from any other program, 
such as an agent in Lotus Notes. In general an event is 
an' incident occurring independent from an activity 
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informing an ^yity ^asyfl^tOFi^^ type t of 
change.* .This : ehar^e,i^ghtbe..^ to the 

WFMS:\-llie^el^or^!^-betwiBep .activity and, the 
event may bp, suoh thaMhe.-activity. requires ;thatc.the 
event is signaleci.tp jt;ptherwi§e th^activity will.npt con- 
tinue beyond a certain : -poirrt. (t is.atso. possible that an 
event signaled, to ^n aetivity-wiH be perceived by./that 
activity and depending : ;pn thatperceptionjmight modify 
the activity*s ongoing processHTg^ An ^y^nt^ight. result 
from anywhere; within, a computer system pr eyervwithin 
networks of computer systearns.; Also the source^ an 
event might be, a hardware device, some softw^ con- 
struct, a human interacting -with^a running computer 
system and so forth. 

The patent application shows how events pan: be 
modelled within a WFMS as a special Kind of activity, 
the event activity. It specializes jn the<sens.e-of object 
orient technology the general : activity, and -inheFjt^ all 
properties of the general activity, therefore, ; a0; event 
(activity) may be associated; wrfclrar*. input. and.oytput 
container and mayi>e th$ source and ti^e ^rget oippo- 
trp! connectors, as wgll the^spurce-and targeto! <teta 
connectors; r e. all constructs and techniques available 
to general activities are ayajUabl^ to ^event ^gtiyities 
) according to thexurrent teaching too. Event$jriay have 
a start condition and may be associate with ^notifica- 
tion.; An event activity is associated witfyan event similar 
tp : propess* activities which; $revassociat§Ci wrthvPrp- 

;grams.^ -.r ; -- : * " m ; * • ^irsw ; <;?c;c-cr?o 

,c Thus an ,"event" ,,d^scrib^ t > .a : .cgpe§ptua! ^and 

semantical entity, wtole the^^ 

of that ^entmodelled.wjtr) ths feature Qf>$Xv£M§. ~#\e 

program^^ssociated with, the- eyeif&^ce j&Me4, event 

generators ai^;repres^ ; thjB nj^n§ ar^ppn^riicts for 

• creatj^g.or^qndlra'd.P^PMla(>ey^v.! ;o f;.:^ .Vsu'Uv 
Figure; 1 reflects multiple .aspects pftthe .^nN^ing 
of events; as a new tyf>e f pf ^acfiy^yT.wi^in a yVf^S 
according the teaching piths current i^^tiQp.vfh^new 
type of actiyityv the:!^^a(nivijy- 1 PQ t is^re^lize^^^ a 
sub-ciass of the class of activities \0 1 ia: rel^tlPh^htP 
ancj inheritance mechanisms f tiie full ^ectrur§.gf (f$a- 

-tures^ and capabilities available to^actiyjttes ? i% : rr^ade 
availabiejto .event activities too. Thus -eve^t act tyttjes 
may ^exploit the. available, notification features AQ%,$)e 
full spectrum of data structure features 103 or.^e. vari- 
ous connector, features .Ijfcq* control connector^ : 1 04. and 
data coonectora-105. Ajso.sbownby Figure 1, is trip rela- 
tionship of ithe model of an.event ipe ^wrth^qn^qr more 
event activities . 1 00 ; arid the- relationship . of r ,a program 
107, an event generator implementing pr handling an 
event, with one or t .rnore : event activities.;!Q6.c .... 

The control connectors originating fr<$m„an event 
activity are treatedas usual, i.e. their truth value of pred- 
icates. potentially associated with those control connec- 
tors contributejo starting conditions-of activitips._Alsp. 
there may be more than one control connector emanat- 
ing from a particular event activity. The usual: navigation 
semantics will evaluate the transition conditions of the 
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■associated^ control- connectors immediately; thus, 
.events will not be physically consumed (in. the sense 
that an event can be- dedicated to a particular control 
connector leaving the event activity node) but are avail- 
5 able formal I originating branches.;. If exclusive validity- of 
an event for a particular.ibranch is required it must be 
expressed; via suitable transition conditions. 

^ An event activity can also be a?target of a control 
connector: TTite rneans that an instance of the corre- 
10 spending event is created (but not signalled) if the tran- 
sition: corxJition of the 'control connector pointing to the 
event activity' is futfilted. Using control connectors point- 
ing to event activities can bevused to explicitly activate 
events within particular process instance contexts. If an 
is r event is activated, the activity .waiting for that event has 
registered tor that event and alLother activities being 
according to the FlowMark process model the target of 
a control connector. briginatingvat the event activity are 
therhpbtential consumers of that event. 
v20 ;r«' Fiigur&i.fl illustrates r how* two^ different cases for 
embedding events as event .activities within a process 
^model can be differ entiatedv exactly as is the case with 
i regular activities.? On the : left side !(t),i the activity A 201 
-must have terminated successfully and the transition 
y25 condrtion>2Q2. between A and.the jevent activity E 203 
.must hav$ been evaluated ,to .'true? t before:the event 
jtocie E is .sensitive for; recognition Jhus, M an instance 
^ofvBt& signdleciy this is not recognize^ before the transi- 
tipn gonditipn between A and E is met. Once E is sensi- 
30 c tjve. for recognition (i. e~ activated) the activity B, 204 has 
Registered, for. the appropriate. instance of E automati- 
cally through the modelled process. graph. Event activi- 
ties for this Jirst .typeh.rra if the 
cause of an event is located at least partially within a 
%35 process model itself. , ... 

b r,>r. v On the, ri^ condition 210 

Jbetweer* y?e«yenf activity E 21 1 : and 4he activity, B 212 
-will ;be evaluated >as soon as the. event E is recognized 
^eypn ^thp aptiyrty A 213 has npt.been terminated. ; Con- 
■40 ^equenOy r ; £ is activated when the process model is 
instantiated, i.e. B has registered for E right away. 
-:..ox:-V^ e nu^ i y^n9^?. n -- e yent activity,, its assc>ciated 
^ut.Gontainer.is TOterializ^ The usual rules for data 
; pt>nneQtoi5 ;dq ; apply. The, output container of an eyept 
: 45 activity is, created by the pyent jgenerator,, associated 
-witJ\;the subject ^ent(see.below}: v ,. t . : ... J; .... 

. . t . ■ . . 4 ' . - t » . • — , - fi- 

ll. Ml • . t ' f.-'^.-'L u ; • • v * - ■ . ■ -j-.-n - ft ......J 

4.a Corrrponent s of Event Management Servicps , 

t 50 ~ . .. t The navigatprjs. the piepe of'the workfiqw r rn^nage- 
v rpent .systenj that performs the n^vigation,through h th9 
process, ,graph.,> For handling events this navigatoir.js 
extended by an Event Management System encom- 
. passing event management service^ which arejnjter- 
H : ss r Qper^ting with the navigator. These event rnanagement 
services .are., logically different componjents which, may 
f 0f ,r^ a y nPt c 9'h<^de with physical means implementing 
..those functions. Figure 3 reflects the major components 
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of the event management services.' The event monitor 
301 is responsible 7 tor keeping -track of awaited and 
posted events/ The event generat rs 302 are pro- 
grams that signal the occurrence of an event to the 
event monitor. The event manager 303 keeps the infor- 
mation about events. 

When the navigator 304 detects that an event is 
expected by particular activities of a process instance 
this is indicated to the event' monitor If the event monitor 
finds a matching entry in its posted event tabie 305 it 
indicates so immediately to the navigator and passes 
the associated data with its response. Otherwise",' the 
event monitor reflects the awaited event by an appropri- 
ate entry in the awaited event table 306. 

An event generator signals the occurrence of an 
event to the event monitor. The event monitor verifies 
the correctness of the event by Consulting the event 
manager. If the event monitor detects a corresponding 
entry in the "awaited event table" this is indicated to the 
navigator. Otherwise, the event is ihserted into the 
"posted event table\ : ; " h 

The tables "awaited event table" and "posted event 
table" are first of all logical objects'. Physically * they actu- 
ally may be implemented as different or as common 
tables. 



4.5 Cancelling Events 



\ - 



ills 



4.4 Tracking of Events 



It can te'perceived that evehts drfei thW event indi- 
cations within <he posted and avyailed eveftt table are 
managed in tabular formats as depicted iri the Figure 4. 
ProcID refers to the identifier of the process instance in 
which thie event is waited tor. The Event! D identifies a 
particular event in this process instance'(as node in the 
process model). The EventNartie refers to th^ category 
of the event and the InputCoWiainer ^iuriin contains the 
actual values of the fields in r^e)a!araated;JnptJt con- 
tainer of the event. * : '\ z '[ \\_ '\ r t '\ 7.V.. 

It has to be hot& ^ needed 
because events having ran incoming ^ntroi connectors 
are drily "activated" if the transition cmciiticwis of the 
incoming cohirol conhertorsi are met and the start con- 
dition is true. An event which is : not activated is not 
reflected in the "awaited ev^t table". Events with no 
irK^mihg control connector ' ^e acSvated at process 
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instantiation time. 

The posted events table is used to store generated 
eyents which are currently not waited for as no potential 
consumer h^r^istered fer'rt.; Such an event is kept in 
this table until somebody ^ registeris' fer - _ii tpotentially. an 
event m&y be keprt "fbrever) or if it is removed via gar- 
bage collection, the ProcID column in this r tabie repre- 
sents an optional value for tupels of this table ahd can 
;be,u£ed tor specifying {particular process instances 
which Wight <x>nsUme the event instance. 



Ah awaited ev§nt can be cancelled in two ways : (1 ) 
as the result" of a notification action, such as FORCE 
TERMINATE or (2) through ah explicit request from the 
user via functions supplied by-the event monitor. When 
an awaited event is cancelled, it- is removed from the 
waited event table and the event: monitor signals the 
compietion'of the event to the navigator. Any outgoing 
control cohnedbr' is treated as if the event- had hap- 
pehed'normally. - }x 5 



4i6 Event Identification 

■ .*■•■ * . ^ 

15 The association of an incoming event, such as 
receiving a letter, with the waited for event is performed 
by comparing the identification fields provided by the 
event generator with the fields defined in the input con- 
tainer plus the fields defined in the input container by 

20 default? which is the process instance identification and 
the : evenf identification. No problem arises if the event 
generator' Itself provides the process instance identifica- 
tion and the event idehtrficatidn. lf the process instance 
identifier is not' supplied, the fields in tile input container 

2$ are compared with the "appropriate -fields delivered by 
the event generator (signature matching). 

vr.*/. - : ~ ' ■ ■ * 

4.7 Event Generator 



;;. i v * 



sb The event generator signals that an event has hap- 
pened by 1 railing the ^nt monitor via the event monitor 
irrteHac<^ can determine when the 

&veht' shoutcf 'Be signalled. This canbe don6 by periodi- 
cally querying the event monitor tb T determine if^a new 

35 ehtry : for the- event generator hasi been erteYed* in the 
awaited e/ent table. Ah event generator may also regis- 
ter itself with 'the event monitor and request that each 
hew 'f egis¥ati6ri f bf an awaited event is signalled to the 
e/ferit generator. : :i - r *"'**• ^ - . j < ■ 

40 The supplied date/time event generator for example has 
a dataWuctUre with a date field and a time field. These 
fields' cSh either be filled by a data cdrinector leading to 
that ev^it or values set ats defaults by the process mod- 
efer.¥he%me^date event generator has registered with 

45 the a/eht rrtonitor tfiat it should be called when a new 
Tsvient is registered. r : . : 



< i 1 v.- i 



4.8 Ev^ Monitor Programming Interface 

so lV The ^ event mohitbr provides an a^jplication program- 
ming interface-' to allow applications to request event 
mohrtbf functions! THe set of functions include requests, 
-aich as querying the posted event table, removing 
entries 11 from "the posted 1 event table, querying the 
55 awaited event table, rerhoving entries* from the awaited 
event table, and inserting entries into the posted event 
"table: ' ' * 
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4.9 Event Registration 



An event -activity ; is always ?as§pciated with an 
event. The. event has a number of properties ; ; the name 
of the program ^ implementing the event genaeator.-the 
name of the.event, v and an indicatoj^whether the event 
generatonshould be started as. part of starting the.ppw- 
Mark server. An- important.. property, is .the : pperatjpn 
mode of the event generator, which detjne$;wh£ther the 
event generator.should be called everyttirp&a new pyent 
is added to the awaited events table or noV If specified.; 
this allows the event generator to keep internal tables 
for efficient processing and does .npt require periodically, 
reading the awaited event table. 



4.10 Event Notification 



Events also inherit (in the sense of object; pnented 
technology) the notion of notification from the, activity. 
Notification allows tp. define .actions which , ate. : taken 
whenever the defineditjme foc,completipn is. exceeded' 
Extensions to the , notif ication mechanism ^l!pw to spec- 
ify other actions than just sending a : qotif icaflqn ^mes- 
sage to a designated person. -These extensions iqcfude 
actions like terminating the activity. .. v; 



4.11 Process Model Additions 



The support of events requires minor additions to 
the FlowMark Definition l^guage (F*OL)t:?£v^ cn; 
Events are registered.(in ^ersense. ; o1 ^g^OL^yja^be 
EVENT section It is- similar. to ; the ,I»BQGR ^ipr? 
which;; supports the registration ;pf . program 
shGrt^^the^FOL-fegi§tratipn of the. event ^Wait for Cus- 
tomer Response? ^ The associated generator prograjpn 
is "MaiiCheckRrogram". The program is st^jed yi §§^a 
result;©! starting the FlowMark sei>rer,,sp^ied 
AUTOSTART,- and is. notif ied whenever. an ^e/ent c is 
entered into the awaited event table, sp,ecrji^ : du§ t Xp 

NOTIFY. .;- • yy r: ' .;..v-rv;, *h **!»oo:.?. j«-jT 

: Event activities of a process^mpctel 
the EVENT^ACTiyiTY . section. TOs.. ; jr^hani^,.is 
almost itjenticai to.the PROGPAM^CTiyiW jseyyv^rd. 
We^event type is specif ied via the EVENT^TYPE Key- 
word followed by ; a string containing the went=type>, A 
particular event type may be specified only once, wjtrjin 
a process model. Figure 6 shows how an event is 
defined. The data s^M^e... n Ey en l lc?©ntrtJteation M 
defines the structure of the input container associated 
with the event... It contains. all relevant information to 
identify tr^e event. This, information is used by the event 
monitor to compare, it with the information suppliedby 
the event generator. The data r structure "Response 
Information" defines the structure of the output con- 
tainer associated with the event. The d§ta js.suppliecj! by 
the event generator. ? •. ■. .ov*- r ' r ■-• 

Notification of ev nts is enhanced to provide the 
capability to force terminate the event, that means that 
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the eygnt is considered complete even if no event has 
been signalled ; during the.specrfied time. Figure 7 
shows how.it cpuld.be ^ecrfied that it should only be 
waited 1 4 days for the customer letter to arrive. 



4.12 Advantages 

The; proposed t methpd pf treating events a^ activi- 
ties has, besides the effect pf offering a seamless exten- 
10 sion. anc^ transition -of, workflow activities, a, number of 
advantages ovef , other possible approaches .that treat 
events differently . ...... . : . 



1 Events follow. Jfje^s^ifie.. metaphor as activities. 



1.1 Control Cpnnectors activate an event. 
. ; ii r^ 1 ? ,pr t edicate^^ on Jf)e incoming , control con- 
. . nectors as well.as the .outgoing control connec- . 
t , ..Jtors, allow ,. to specify . which event should be 
20 j waited, for and which, activity should be exe- 
cuted as the result of the. happening of an 
; ; - ., t , event.^yents withput an incoming control con- 
. •-■!.;'. . .^-n^^iPT |n^edigtely,a^yated as are start 
< -t activities. ,. - T . • ». t.« 

25 1 .2 Data Connectors allow to fill the input con- 

tainer with the event relevant data. No hew 
mechanism is required toj^entify. the. instance 
of the event for which it should be waited for. 
tri .1 .3. Jnput, Containers identify to.a^iyitjes what 
30 /-I . the "context is in .which, they are .called. The 
^ ^ . - same is.trMe.for event. activities as the .cpntents 
r : . \ *\ of the input^container. identifies the particular 
V . , characteristics of the ; .eyent which is waited for. 
j., 1.4,PLrtput C^maineirs contains the process 
35 V v r .€|l ?yant irrtprnratictfi ^generated by an activity. 
; , I? I ^ r. or ^enj activities, the event signall er proyid es 
^ J-ihi^ ii^brmatipn, for ^ampje, the identrf i^ation 
" of the letter which has been, received, 'which is 
?>-r*»o. f , process relevant informaticfi.,. 
Ir^v^.^rVCNotitiC^ allows ip specify what should 
". ' tiapf^Bn if an activity hSs not been connpleted 
.* within a defined time limit^fhe same 'behavior 
„ ,is true for event activities, where this inecha- 
v r l t; lii5ni.is used, in the sameWayl . . /..JJ <r . 
45 - , \ 6 ^Events can.be har^feJd' within Spheres, of 
Joint Compensation the same way.as jactiyi- 
. ties. 



: - -1 ■ 



,1/2 Everijis can be gr^l«lfy/rra^ 
50 : - way as are actryrti^s.: . -\ e \ \ lr ^^T 
. 3 Events can be described Tn the FldwM^k'p^ini- 
. tion Language with similar . constructs as program 
, , activities.. ;t , % . . . - 

4 Trjeating events as ^ac$wties.ajlows to re-us^^ trip 
55 " code used* for processing probes^ rripde!.sT sijch as 
navigating the graph. Fie-use bt this code Provides 
a number of advantages, such as 
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4.1 Less errors 



* principles of object-briehtation: 

3. A computer system according to any of above 

claims .. . , , , 

wherein said event : activity is associated with 

an event, and, , „ I W... 

wherein said event-activity may have associ- 
ated with it ah iriput-coritainer and/or an output-con- 
tainer, and ~ t \ . Z . 

wherein said event-activity may be the 
source and/or target of one or more control-connec- 
tors, and 

wherein said event-activity may be the 
source and/br target of one or more data-connec- 
toris, and v: - 

wherein said event-activity may be associ- 
ated with a notification-mechanism allowing to 
freely 'define at least one action to be performed by 
th& woridl^process-environmerrt if said event- 
' activity is" not completed within a freely defined time 
period. 

4. A computer System according to claim 3 
wherein said event is implemented by an 



4.2 Easier testing - 

5 Events can.bie monitored the same way as other 
activities via the process in^tjance-moriitor. 



All in all these advantages help, to comp^ctify the 
overall system, contribute to minimize the implementa- 
tion effort and thus increase the responsiveness of the 
WFMS. " r ' " 



4.1 3 Example 



A simple process model in Figure 8* illustrates the 
usage of events. In a claims'prqcessing application of 
this example additional info is required from a customer 
801 . The process waits until information is received 802. 
If the customer responded vA fax, thefex is processed 
with a certain piece of software 803, otrjerwjse another 
piece of softwarie is used 804. t . 

Figure 9 shows the definitions of the most important 
data structures being of importance within the example 
of Figure 8. Finally Figure' 10 \i a ^ visualization of thie 
event modeled as £n : event atfivfty "Wart for 
Response" in lines 5 to 9 within the proems model of 
the example of Figure 8. Figure 1 6 further demonstrates 
in lines 14 to 21 usage of control connectors arid in line 
21 to 31 usage of data connectors for the event activity. 

5 Acronyms 

DB Database 

FDL FlowMark Definition Language 
WFMS Workflow Management System 

Claims 

1. A computer system encompassing one or more 
computers storing an implementation of a process- 
model for a workflow-process-environment said 
process-model managed and executed by said 
computer system, said computer system being 
characterized by 

at least one event-activity encompassed by 
said process-model said event-activity being 
implemented as an activity of said workflow- 
process-environment 
and 

said event-activity managing an event occur- 
ring internal or external to the workflow-proc- 
ess-environment. 

2. A computer system according to claim 1 
wherein said event-activity being implemented by 
inheriting features and capabilities of the class of 
activities or of a sub-class thereof according to the 
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15 



20 



25 



30 



35 



40 



45 



SO 



event-generator. 



5. A computer v system according to claim 4 

t vv: wherein ' J said ' event-generator is imple- 



l - mented as a program. 



6. A computer system according to anyone of claim 3 
to o 

^o.rsL) : w ^^irt i; gaid^dh aufomaticafiy terminate 



said everfcactiviiy. 



7. A computer system according to any r of above 
claims 

r *i£ r ;mi : ^vt^ergjH ? s£id process-model encompassing 



55 



afieast one butgblhg-cbritroi-connector said event- 
activity being the source and a target-activity being 
the target of said outgoing-control-connector, and 
*"* ?H :rv?tk 'wherein * said putgCing-control-connector 
J f optionally iriay be associated with a logical predi- 
cate as outgjoin^-transitibn-conditioh; and 
; - wherein ^id wbrkfibw-prbcess-environment 
J activates said tog^t-activrty if said event is signaled 
to ' said waiting "event-activrty and finally said 
1 eviertacfivity terminated and if said outgoing-tran6i- 
tion-condition evaluates to true. 

8. A computer system according to any of abo* 
claims 

wherein siaid worwiow-prbcess-environment 
' d activating skid event-activity automatically when 
1 iristantiatirigsaid process-model if sab event-activ- 
ity is no target of a control-connector. 

9. A computer system according to claim 1 to 7 
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wherein said proces&tnjxl^k encompassing 
at least one incoming-control-cbnnector said event- 
activity being the target and^a^ource-activity being 
the soli rice of said incoifiing-cbntror-cohhedpr, and 

wherein said incoming-control-cbnnector 
optionally may d£ associated with a logical predi- 
cate as incoming-transitionrconditibh, and 

wherein said wbrkflow^rocess-environment 
activates said event-activity if said squrce : activity 
terminated and said incoming-transition-cbnclition 
evaluates t6 true. 



10. 



A computer system according to cl^im J to 9 

... wherein said workflow-processrenyirpnment 
registers said event-activity as awaiting consumer 
of said event pnce said e^ent-actjyity is activated by 
said workfioyv:prc<;ess-envirp^meht, and t ,. 

wherein further said wprWiqw^^roces^envi- 
ronment registers said event as po^t^.-went,pnce 
the occurrence of said event ik ..signaled by said 
event-generator. 



£»"*: : :..t::' 



an event-management^ and 
inter-op^ating. Y y^h [:s^. > ..i^^gw;ra«gj^to^ 

... and .... .... ''. 



f- '\ 



14. A computer system accordincito claim 1,3 



TO 



/5 
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1 1 . A computer system ( according to qla&m, 7 A tp J 0, 

wherein said ^ target-activity . 'is, Activated by 
said workflow-process-envirorirtient if as a first con- 35 
dition said event-activity terminated and if as a sec- 
ond condition , saic^ out^oipg-transltipn-conditioii 
evaluates to true indeperiderit af which point in time 
and in which sequence said first and said second 
condition are fulfilled. 
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. ... . .... . ••■*' "JV;.-«?V7; ISjliOr.ICO A I" 

12. A computer system according tp claim 10 jenjcom- 
passing ayyprWIpw-nay^ navigation 
of operation trough the prcc^^aphpf said, proc- 
ess-model and said computer system being further 35 
. characterized by. ; . . 
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said, event-manage Went -sysfe^jsilconpasses 
.. . t^e component of an ^ent-n^rYrtpr aclryjnister- 
ing. awaited events, 'jn.. at.. lea^t r ciQg jiwaited- 
. event-table and, further; ^qriinisteHng signaled 45 
eventsyinaileast one p^t^:eyjeh)t-t^e. r and 
.* _ wherein $aid ev^nt-genera^or is signal- 
ing the oQCurrehiQe 6l said. event tp said, event- 
monitor. "... , > . , : 
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13. A computer . system ac^rdi^ claint 12 - 

wherein said eveht-nranageme^t-|;>^em 
encompasses the cqmponent pf .an^eyent-manager 
maintaining , intomation on i said event allcwjjng to 
verify x»rrectn.ess of said event if said event is being 55 
signaled. ... * : 



wherein said workf lowrnavigator sends, if it 
detects that said event-activity is awaiting for said 
event, an awaited-event-hotification to said event- 
monitor and if then said event-monitor detects a 
matchihg^posted-everit-indication in said ppsted- 
event-table said event-monitor indicates said event 
together with event-data to said workf low-navigator 
or if ^herwise no. matching F^sted-went-notifica- 
tion Is detected said event-mbhitor stores an 
awaited-event-indication in said awaited-event- 
table, and 

wherein said event-generator indicates the 
occurrence of said event by a posted-event-indica- 
tion to said event-monitor which verifies said 
pbst^-^ent-ihpication by. consulting said event- 
manager and*thfen"'&b 

tidh ih ^ said ^pp^J-eye^ said 
went-moriitbr detects a matching awaiting-event- 
Indication in 'said. awa r tin$7^^hY : teble it indicates 
this tbgether'with even't?d^ta to said wbrkflow-navi- 
gator. 



.1* 



.It. ir 



A corpp.uter system according to . claim 14 
V v^^' 1 ! 53 ^ ^eht^eneratpr p informed, if 
said awarted-eyent-ihdication is . stored jn said 
iawa^:event:tab!e. .pq this, awaited-eyeht-indica- 
tiort 
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1 EVENT 'Wait for Customer Response' 

2 EVENT_GENERATOR 'MailCheckProgratn' 

3 AUTOSTART 

4 NOTIFY 



FIG. 5 
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EVENT ACTIVITY 'Wait for Response* 
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('Event Identification', 'Response Information') 
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EVENT ' Wait for Customer Response * 
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END 'Wait for Response* 
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EVENT ACTIVITY 'Wait for Response ' 
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EVENT 'Wait for Customer Response' 
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AFTER 14 DAYS FORCE FINISH 
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1 STRUCTURE 'Event Identification* 

2 'case number' : STRING ; 

3 'customer name* : STRING^ 

4 END ' Case I nf ormat ion * " 0 - \ 

5 STRUCTURE 'Response Information* 

6 'response ID' : STRING ; 

7 'type' : STRING ; 

8 END 'Letter Information' 

9 STRUCTURE 'Case Information' 

10 'case number' : STRING ; 

11 'customer name' : STRING ; 

12 'response ID' : STRING ; 



FIG. 9 
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1 PROGRAM ACTIVITY 'Request Customer Info' 

2 ('Default Data Structure', •Case Information ) 

3 PROGRAM 'RequestCuetomerlnfo' 

4 END 'Request Customer Info* r 

5 EVENT_ACTIVITY 'Wait for Response' ./ 

6 ('Event Identification*, 

7 'Response Information' ) 

8 EVENT TYPE 'Wait for Customer Response* 

9 END 'Walt for Response' . . 

10 PROGRAM ACTIVITY 'Process Fax* 

11 ( - Case Information ' : iV * Def aulfcDafcaStrueture; ) 

12 PROGRAM Process 5 Fax' 

13 END * Process Fax '^ ^ - ■ v 

14 CONTROL FROM 'Request Customer Into 

15 TO * Wait for Response* 
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21 WHEN 'type = '*'* LETTER" * \ 

k 
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23 TO 'Wait for Response* 
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25 TO 'Process Fax' 
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(54) Events as activities in process models of workflow management systems 



(57) The present invention relates to the area of "1 
workflow management systems (WFMS). WFMS exe- 
cute a multitude of process models consisting of a net- 
work of potentially distributed activities. The current n . 
invention is dedicated to the implementation of events 
within WFMS. The current invention teaches to imple- 
ment events like any other process activity. 
Thus events are implemented as event-activities, a spe- 
cial type of an activity within said WFMS. Such an 
event-activity can manage an event occurring internal or 
external to the WFMS. 

This approach allows to make all features available to 
common activities also accessible to event activities; 
examples are: input-container and/or output-container, 
control-connectors, data-connectors, notification -mech- 
anisms, predicates associated to control connectors 
forming transition conditions and many more. A control 
connector leaving, an event activity, which optionally 
may be associated with a logical predicate as outgoing 
transition condition, allows the WFMS to automatically 
activate a target activity if said event activity terminated 
after the event has been signaled to said event activity 
and if the outgoing transition condition evaluat s to true. 
Similar an incoming control connector, which optionally . 
may be associated with a logical predicate as incoming 
transition condition, allows a WFMS to automatically 
activat an vent activity if the process activity being the 
source of said incoming control connector terminat d 
and if said incoming-transition-condition evaluates to 



"fitrue. - t ■; ; ; v.-:- >:-,. ; .. ' v 

This invehtion-also teaches to, extend the navigator of a 
L1J?r WFMS i by an- event management system which inter- 
.. jOperaJe^WfcH^ to deliver above mentioned 

*lunctiMaP^Tne^wept mariagerhent system encom- 
passes the component of an event monitor administer- 
ing awaited events in a awaited event table and further 
administering signaled events in a posted event table. 
The event management system further encompasses 
the component of an event manager maintaining infor- 
mation on events allowing to verify correctness of an 
event. 
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